Some events taking place in an online gaming system should be multicast to a large group of end-users connected to the system. For example, a notification about the start of a tournament should be sent out to all the end-users registered to participate. Traditionally, this type of distribution mechanism is implemented directly inside the game servers. This solution, however, limits the ability to scale efficiently as the number of end-users grows. The main reason for this is that all end-users that should receive the event notification must somehow be connected to the single game server where the event was triggered. Since the capacity of a single game server is limited, there is an upper bound on the number of end-users that a game server can manage to multicast to.
The multicast problem is similar to the scalability problem that arises when trying to broadcast large amounts of data to many end-users in real time, e.g. live streaming on the internet. The main difference is that multicast, as opposed to broadcast, is directed to a specific set of end-users. The game servers must distinguish between different end-users and determine which ones that should receive a specific message. Simply broadcasting everything to everybody is not an option here, since this would violate security principles of sensitive data. It would also generate unnecessary data traffic which increases the operating costs.
Another drawback of the described traditional multicast mechanism is that it is part of the gaming domain, i.e. the logical group of applications that manage game related logic. However, the gaming domain should be kept as clean as possible and optimized for its purpose—to manage game states and uphold the game rules. By connecting end-users directly to the game server for multicast purposes, the game server responsibility is stretched outside the gaming domain. The game logic must then also consider details about end-user connections that are of no relevance to the game itself. The mix of multicast connection logic and game logic does not only increase the complexity of the game servers, it also limits the performance of each game server. An application can typically be optimized for efficient IO throughput or for efficient rule processing—but not for both. The mix implies a trade-off where the game servers need to sacrifice game rule processing performance to handle large numbers of end-user multicast connections.